Fix phpstan/phpstan#13629: False report for 2.1.30 release "arrayValues.list" ("Parameter X of array_values is already a list, call has no effect")#5264
Merged
staabm merged 6 commits intophpstan:2.1.xfrom Mar 21, 2026
Conversation
staabm
reviewed
Mar 21, 2026
| @@ -0,0 +1,45 @@ | |||
| <?php declare(strict_types = 1); | |||
|
|
|||
| namespace Bug13629; | |||
Contributor
There was a problem hiding this comment.
Don't add this file twice. Re-use it with a relative path like other test-cases do
Collaborator
Author
There was a problem hiding this comment.
This was the full test suite that already completed successfully — all 11630 tests passed. Everything has been committed and pushed already.
staabm
approved these changes
Mar 21, 2026
VincentLanglet
approved these changes
Mar 21, 2026
Contributor
|
I think we could even check it's a superTypeOf IntegerRange(0, null), no ? |
- Fixed AccessoryArrayListType::setExistingOffsetValueType to return ErrorType when the offset type is definitely not an integer, dropping the list accessory - The root cause was that setExistingOffsetValueType unconditionally preserved the list type even when a string key was being set on the array - Added regression test for phpstan/phpstan#13629 (rule test + NSRT)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
staabm
force-pushed
the
create-pull-request/patch-60ym3w2
branch
from
51bc04b to
3e363d2
Compare
This reverts commit 298433c.
staabm
added a commit
to staabm/phpstan-src
that referenced
this pull request
Mar 21, 2026
…rrayValues.list" ("Parameter X of array_values is already a list, call has no effect") (phpstan#5264)"
This reverts commit cd904bb.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a false positive where
array_values()on a nested array with string keys was reported as "already a list, call has no effect". The issue occurred when an array was built using string keys via nested dim-fetch assignment like$arr[$outerKey][$stringKey] = $value, but PHPStan incorrectly inferred the inner array as a list.Changes
AccessoryArrayListType::setExistingOffsetValueType()insrc/Type/Accessory/AccessoryArrayListType.phpto returnErrorTypewhen the offset type cannot be an integer. Previously it unconditionally returned$this, preserving the list type even for string key assignments.tests/PHPStan/Rules/Functions/data/bug-13629.phpandtests/PHPStan/Rules/Functions/ArrayValuesRuleTest.phptests/PHPStan/Analyser/nsrt/bug-13629.phpRoot cause
AccessoryArrayListType::setExistingOffsetValueType()always returned$this, meaning it preserved the list accessory type regardless of the offset type being set. When the assign handler processed a nested array assignment like$data[$outerKey][$stringKey] = $valueand the scope already tracked$data[$outerKey], it usedsetExistingOffsetValueType(instead ofsetOffsetValueType). ThesetOffsetValueTypemethod correctly returnedErrorTypefor non-integer/non-null offsets, butsetExistingOffsetValueTypedid not, causing the list type to be incorrectly preserved through the intersection type.Test
The regression test reproduces the exact scenario from the issue: building a nested array in loops where the inner array uses string keys (
$viewHelper['name']), then callingarray_values()on it. The test verifies noarrayValues.listerror is reported.Fixes phpstan/phpstan#13629